With the substantial increase in use of the Internet and, particularly, the World Wide Web ("Web"), electronic commerce is emerging as an important tool for service providers. Consequently, a need has developed for a system of providing service instructions and rules of interaction between parties to the service.
FIG. 1 describes a conventional system in which informal instructions for correct use of a service are provided by a computer program where another computer program uses and benefits from the service. The illustrated system provides an example of how a computer program which can be executed to provide some useful service might, with techniques well known to those skilled in the art, have its "instructions" for use defined informally as a guide, a manual or some other form of text.
A computer program 100 executes on a computer or processor and provides a service FUNC 102. This program 100 has a number of defined interfaces so that other programs can call it to obtain functions from the service FUNC 102. For example, three call interfaces 104, 106 and 108 (e.g., method calls on the object FUNC 102 in object programming terminology) are provided. Typically, these interfaces will have a name allowing them to be called (e.g., F1, F2 and F3) and will allow parameters (e.g., p, p1 and p2) to be passed on a call. The instructions 110 on correct use of the service FUNC 102 might state, for example, that the service is initialized by making a call to the interface F1 104 and that, after this call is complete, interface F2 106 may be called multiple times. Furthermore, the instructions might state that the output parameter p2 passed back from the initial call on F2 106 should be reused as an input parameter on the subsequent calls to interface F2 106. These instructions 110, in electronic or hard copy format, would typically be provided as text or as a guide or manual describing the correct use of the service 102. Another computer program 112 which uses the service FUNC 102 provided by program 100 is written in a way which follows the instructions 110 for correct use of the service 102 as specified. Specifically, the program 112 makes an initial call 114 on the interface F1 104.
This call 114 returns an output parameter value p2. The program 112 then executes some other actions, and then makes a first call 116 to interface F2 106 passing in the parameter value p2 as specified in the instructions 110. After some further actions, program 112 makes a second call 118 on interface F2 106 of program 100 also passing in the parameter value p2 as input.
The system of FIG. 1 requires a programmer to read the instructions 110 and to write the program 112 with the instructions 110 in mind. There is a need for a system which eliminates the need for such programmer effort. There is also a need for a system which provides unambiguous rules of interaction for both parties to a service transaction beyond that of simple interface instructions.
FIG. 2 provides a conventional example of informal instructions for correct use of a service 200 provided by, in this instance, a human agent and used by humans who mail documents to and make phone calls to a service provider. As in the preceding example, guidance on the correct use of the service 200 is still necessary in most cases. This guidance is typically provided as a guide or manual or other form of text to be understood by human users.
In FIG. 2, the basic service 200 is an insurance claim handling service. In this case, it is assumed that the service 200 is handled by one or more human agents 202 who can interact with the human claimant 204. The interactions 206, 208, 210 and 212 which are needed to proceed through the claim process involve either completing and mailing forms or making a phone call to pass simpler information. Interaction 206 involves reporting an accident report over the telephone. Interaction 208 involves mailing a claim form. Interaction 210 involves providing a police report number over the telephone. Finally, interaction 212 involves receiving a payment check. The informal instructions 214 on using the service 200 include text describing the required sequence of interactions. The arrows 216, 218, 220 and 222 show that the human claimant must execute each of the actions specified in the instructions 214 in the proper order, with the correct initial information for forms, etc. Finally, supporting computer programs 224 or other services may have to be taken advantage of by the claim processing service 200 itself to complete the service requests. Arrows 226 and 228 show interactions between the claim processing agent 202 and the supporting services 224. These interactions are part of the implementation of the business service 200. Hence, they are not discussed in the instructions 214 for use of the service 200.
While this system, like the system of FIG. 1, provides informal instructions for interaction with a service, it fails to provide complete rules for all parties to a transaction which can eliminate the need for human interaction.
A third example of a conventional service system incorporates the object interfaces defined by the Common Object Request Broker Architecture (CORBA) standard illustrated in FIG. 3. This system includes a CORBA interface specification 300 for objects of type X. The interface specification 300 is written in Interface Definition Language (IDL) and includes method interfaces f1 and f2 on objects of this type. The interface specification 300 includes signatures or parameter list specifications for each of these methods and defines attributes such as a1 and a2 specifying their type. The interface specification 300 can be processed by an IDL compiler to produce the client proxy stub 302 for X objects and the Class implementation skeleton 304. A key objective of CORBA is to allow use of different languages. This is illustrated by showing that, in this case, the implementation skeleton 304 is written in C++ but the client proxy stub 302 is for use in C programs. A sample client program 306 which is written in C and includes the X client proxy stub 302 can make calls on X object instances. Program 306 can be compiled (using a C compiler) to produce the executable client program binary 308. Meanwhile, an implementor of class X can add method bodies 310 written in C++ into the X class skeleton 304. Also an implementer can add C++ declarations 312 for each of the attributes. A C++ compile step produces the compiled implementation 314 of class X included in some object server. The client program 308 is able to make calls on all the methods defined for class X over interconnect 316. The CORBA infrastructure will deliver the calls to the correct server and provide local remote transparency, if necessary. Using these calls, separate X instances 318, 320 and 322 can be 20 created and manipulated. Each instance has its own private set of attribute values holding its state.
Thus, CORBA allows for complete specification of the interface for an object type. It also enables automated processing of this interface specification to support clients in one programming language using instances of the object implemented in a different programming language. This automation also covers routing the method calls with local-remote transparency, where necessary. However, this system only deals with interfaces with parameter lists and types. The interface specification does not provide formal rules for interaction between the parties. Furthermore, the interface specification does not provide for multiparty interactions.
The present invention is motivated by a need to be able to provide automated business services, accessible to many clients via widely accessible public or enterprise networks. The service may be implemented by using other business services typically provided on other service processors, belonging to different organizations and also reached via widely accessible public or enterprise networks.
Therefore, there is a need for a service contract which describes the requirements (including the formal rules of interaction) of the provider of the service as well as of the user. There is also a need for a service contract which is formally specified in a language where it can be compiled and used to generate parts of the user and service applications which enforce the interactions. Finally, there is a need for a service contract which supports multiparty interactions.